In processor controlled embedded devices, the firmware for operating the processor may be updated to add functionality or obtain enhancements to existing functionality. During the process of updating firmware, the firmware image must be written to a firmware memory, which may comprise nonvolatile memory, such as NVRAM, flash memory, EEPROM, etc., as is known to those of skill in the art. If only one firmware image is stored in the firmware memory, the process of writing the firmware overwrites the existing firmware image. If the firmware update becomes corrupted, such as by incorrect transfer of data or being interrupted by a power cycle, etc., the only copy of the firmware is not usable, and the embedded device ceases to function. If the method of updating the firmware involved code in the firmware image that was corrupted, it is also no longer possible to correct the problem by updating the firmware again, and the embedded device with the corrupted firmware must be replaced.
One typical method of handling the issue is to provide two copies of substantially all of the firmware in the embedded device in one or more firmware memories. This provides robustness as one firmware image is left intact while the other is being updated, but at the cost of requiring firmware memory that is twice the firmware image size, which is a sizable cost impact to a typical embedded device.
Another strategy is to provide a source processor node with a great deal of nonvolatile memory in a network with embedded device target nodes. The embedded device target nodes comprise volatile memory, which is lower cost, for temporarily storing a firmware image. On power up or reset of the target embedded device processor, a small amount of firmware in a nonvolatile memory causes the processor to request the firmware image from the source processor node. The source processor node will have sufficient nonvolatile memory to handle updates to code images for the target embedded devices and to handle potential corruption to update images. The nonvolatile storage requirement for the target nodes is smaller and the system is robust to disturbances during firmware updates, but the power on time is greater, since the full firmware image does not reside on the target embedded device.
Another method is to store the full firmware image at the embedded device, as well as a fixed backup image. The backup image is simpler, is not changed, and is only used when the full firmware image is corrupted. If the full firmware image is corrupted, the backup image is used to provide operation of the embedded device, and may be used to update the full firmware image, either from a source node in the system or from an operator loading code from a maintenance interface. However, the backup image is only for backup and is not intended to be upgraded. Further, the boot section that determines whether the full code image or the backup image is to be used is also not intended to be upgraded. Because the boot section and the backup image cannot be updated, neither improvements to algorithms nor fixes to problems can be made to those sections. In addition, there can be no changes to the sizes of the boot section nor the backup image memory.